Mobile apps have a distinctive problem. Most are currently standalone programs, that often just converse with an app server run by the company that wrote the app. The apps do not have URL links within them.
It is much harder for a search engine, which is optimised to search the Web for webpages, to search arbitrary apps. There is no standard syntax equivalent to an URL or URI to enable this.
To enable such and other functionality in mobile apps has been termed ‘deep linking’ within apps. (The term also has an earlier use that refers to standard web pages and URL links within them. This submission does not use that earlier meaning.)
Major companies have several projects aimed at defining deep links. Facebook Corp. has App Links. Google Corp. has App Indexing. Twitter Corp. has App Cards. There are also several startups, like Branch Metrics Corp., Quixy Corp. and URX Corp., with their own initiatives. The syntax and functionality vary between these company-specific efforts.
Much of the prior art on deep links has been where a user of a mobile device gets a deep link by some means, and then picks it. Or the deep link appears inside a first app, that the user is running. Then by various means, the app pointed to by the deep link is installed on the device, if the app is not already present. The app is run. This does not involve a communication between apps on different devices. And even when the apps are on the same device, when the second app is run, it might not interact with the first app.
Another issue with mobile devices has been the use of ad blockers, to block popup ads or ads appearing inside a mobile app. From the point of view of an ad server (i.e. ad publisher) this can be an existential problem. Also perhaps too for a firm which makes a mobile app where part or all of the revenue comes from showing ads.
Yet another problem with mobile devices is the lack of the equivalent of cookies for mobile apps, compared to the use of cookies with browsers on desktop machines.